其實很多團隊裡面有些該被時代淘汰的開發/命名/排版規範，或是該規範有其適用的 context，現在產品開發可能已經不具備該 context 了。
但團隊中的一些老鳥，可能因為沒有去確認該規範所對應的 context ，或是不明究理的一脈傳承下來的限制（就跟猴子拿香蕉就被噴水，之後的猴子都不敢拿香蕉，一拿香蕉就會被其他猴子圍毆），也可能是因為「習慣」了不想改，導致團隊開發生產力低落，又得不到對應的好處。
一個明顯的例子，就是匈牙利命名法，在靜態型別語言 + IDE 輔助之下，已經不需要把型別掛在變數名稱或方法名稱上。
另一個則是禁用 C# 裡面的 var，其實工具也都支援一鍵轉換了，當你詢問團隊成員為什麼不能用時，他們的回答是：「我也不知道，就不能用。」這時就會知道這個團隊存在著這樣的根本問題。
當然，還有那種 Data Class 身上不能有方法，或是 interface 自己是個 folder/namespace 的情況。
很多人寫程式真的是都是用背的，沒去了解背後的脈絡，沒去了解限制/規範想要達到的目的，透過犧牲一些自由度以帶來更大的效益，卻一味的遵循著「#前人的教誨」而不知其所以然，其實是很浪費的。
--
當然啦，如果是在既有的產品中，無傷大雅的 name style，我的確傾向 #一致性 優先於 #正確性，但同樣的團隊成員新寫的產品，就應該思考一下，究竟怎樣才是最有生產力、最有效益的作法。
Search